packages/runtime/test/client-api/relation/self-relation.test.ts (1)

7-7: Avoid double-running providers: drop describe.each and read provider from env

With the CI matrix now passing TEST_DB_PROVIDER, keeping describe.each runs both providers inside each job, doubling runtime and causing redundant DB work. Read provider from a helper and use a single describe.

Apply:

-import { createTestClient } from '../../utils';
+import { createTestClient, getTestDbProvider } from '../../utils';
@@
-describe.each([{ provider: 'sqlite' as const }, { provider: 'postgresql' as const }])(
-    'Self relation tests',
-    ({ provider }) => {
+describe('Self relation tests', () => {
+    const provider = getTestDbProvider();

Also applies to: 2-2, 6-8

packages/runtime/test/client-api/relation/one-to-one.test.ts (1)

7-7: Align with env-driven provider selection; remove per-file provider parameterization

Same duplication issue. Use a single suite and fetch provider from utils.

Apply:

-import { createTestClient } from '../../utils';
+import { createTestClient, getTestDbProvider } from '../../utils';
@@
-describe.each([{ provider: 'sqlite' as const }, { provider: 'postgresql' as const }])(
-    'One-to-one relation tests',
-    ({ provider }) => {
+describe('One-to-one relation tests', () => {
+    const provider = getTestDbProvider();

Also applies to: 2-2, 6-8

packages/runtime/package.json (1)

11-12: Good: provider-specific test scripts added

These help local runs against a single backend.

For parity with "test", consider including typecheck:

-"test:sqlite": "TEST_DB_PROVIDER=sqlite vitest run",
-"test:postgresql": "TEST_DB_PROVIDER=postgresql vitest run",
+"test:sqlite": "TEST_DB_PROVIDER=sqlite vitest run && pnpm test:typecheck",
+"test:postgresql": "TEST_DB_PROVIDER=postgresql vitest run && pnpm test:typecheck",

packages/runtime/test/plugin/entity-mutation-hooks.test.ts (2)

367-369: Fix misleading comment: mutation is NOT persisted

The assertion expects zero records, so the comment should reflect rollback/no write.

-            // mutation is persisted
+            // mutation is not persisted

---

212-218: Avoid relying on array index in hook read-back

Using index 0 couples to ordering. Prefer matching by predicate.

-                            const afterEntities = await args.loadAfterMutationEntities();
-                            if ((afterEntities![0] as any).title === 'Post1') {
+                            const afterEntities = await args.loadAfterMutationEntities();
+                            if (afterEntities!.some((e: any) => e.title === 'Post1')) {
                                 post1Intercepted = true;
-                            }
-                            if ((afterEntities![0] as any).title === 'Post2') {
+                            }
+                            if (afterEntities!.some((e: any) => e.title === 'Post2')) {
                                 post2Intercepted = true;
                             }

packages/runtime/test/client-api/mixin.test.ts (1)

71-79: Make error match case-insensitive for cross-dialect stability

Different providers/drivers vary error casing; regex is more robust.

-        ).rejects.toThrow('constraint');
+        ).rejects.toThrow(/constraint/i);

packages/runtime/test/policy/migrated/deep-nested.test.ts (1)

468-486: Harden duplicate-constraint assertion against casing differences

Use a case-insensitive regex to reduce flakiness across SQLite/PG.

-        ).rejects.toThrow('constraint');
+        ).rejects.toThrow(/constraint/i);

packages/runtime/test/client-api/relation/many-to-many.test.ts (1)

7-7: Include provider in suite title for clearer test output

Keeps CI logs self-descriptive when running per-provider.

-describe.each([{ provider: 'sqlite' as const }, { provider: 'postgresql' as const }])(
-    'Many-to-many relation tests',
+describe.each([{ provider: 'sqlite' as const }, { provider: 'postgresql' as const }])(
+    'Many-to-many relation tests for $provider',

packages/runtime/test/policy/migrated/auth.test.ts (1)

539-539: Make error assertion dialect-agnostic

Use a case-insensitive regex so both SQLite and Postgres messages pass.

-        await expect(db.post.create({ data: { title: 'title' } })).rejects.toThrow('constraint');
+        await expect(db.post.create({ data: { title: 'title' } })).rejects.toThrow(/constraint/i);

packages/runtime/test/policy/migrated/nested-to-many.test.ts (1)

385-385: Remove debug logging from tests

Avoid noisy CI output.

-        console.log(r);

packages/runtime/test/client-api/count.test.ts (1)

37-39: Confirm select: true semantics for count

If select: true is an alias for _all, ensure both dialects return a number (not { _all: number }). Otherwise prefer { select: { _all: true } } for clarity.

packages/runtime/test/client-api/undefined-values.test.ts (2)

7-7: Trim trailing space in suite name

Minor nit: trailing space after “tests”.

Apply:

-describe('Client undefined values tests ', () => {
+describe('Client undefined values tests', () => {

---

22-39: Add a nested-where undefined case

Consider adding a nested relation filter with undefined fields to ensure deep pruning is consistent across dialects.

packages/runtime/test/client-api/type-coverage.test.ts (1)

83-85: Provider guards are appropriate; add brief rationale

Skipping for SQLite here makes sense due to array support differences. Add a short comment so future readers know it’s intentional.

Also applies to: 129-131

packages/runtime/src/client/crud/dialects/base-dialect.ts (1)

48-51: Make return type explicit for transformOutput

Return type is inferred as unknown; make it explicit for clarity and consistent overrides.

-    transformOutput(value: unknown, _type: BuiltinType) {
-        return value;
-    }
+    /**
+     * Post‑read scalar conversion (e.g., parse JSON, decode bytes, cast numerics). Default: passthrough.
+     */
+    transformOutput(value: unknown, _type: BuiltinType): unknown {
+        return value;
+    }

packages/runtime/test/client-api/filter.test.ts (2)

6-6: Remove trailing space in describe title

Tiny nit: "Client filter tests " has a trailing space.

-describe('Client filter tests ', () => {
+describe('Client filter tests', () => {

---

77-127: Make provider branching exhaustive to surface unsupported providers early

Add an else branch (or switch) to fail fast if a new provider is introduced.

-        if (client.$schema.provider.type === 'sqlite') {
+        if (client.$schema.provider.type === 'sqlite') {
             // ...
-        } else if (client.$schema.provider.type === 'postgresql') {
+        } else if (client.$schema.provider.type === 'postgresql') {
             // ...
+        } else {
+            throw new Error(`Unhandled provider: ${client.$schema.provider.type}`);
         }

Also applies to: 127-187

packages/runtime/test/policy/basic-schema-read.test.ts (1)

75-76: Strengthen assertion: verify identity instead of just truthy

Keep the simplified flow but assert the returned row matches the created user id for better coverage.

-        await expect(authClient.$qb.selectFrom('User').selectAll().executeTakeFirstOrThrow()).toResolveTruthy();
+        await expect(
+            authClient.$qb.selectFrom('User').select(['id']).executeTakeFirstOrThrow()
+        ).resolves.toMatchObject({ id: user.id });

packages/runtime/test/client-api/computed-fields.test.ts (1)

12-29: Prefer referencing columns via ref to avoid treating strings as values

When building computed expressions, pass refs instead of raw strings to ensure correct quoting across dialects.

-                        upperName: (eb: any) => eb.fn('upper', ['name']),
+                        upperName: (eb: any) => eb.fn('upper', [sql.ref('name')]),

packages/runtime/test/utils.ts (3)

18-24: Normalize env var to lowercase for robustness

Accept TEST_DB_PROVIDER in mixed case.

-export function getTestDbProvider() {
-    const val = process.env['TEST_DB_PROVIDER'] ?? 'sqlite';
+export function getTestDbProvider() {
+    const val = (process.env['TEST_DB_PROVIDER'] ?? 'sqlite').toLowerCase();
     if (!['sqlite', 'postgresql'].includes(val!)) {
         throw new Error(`Invalid TEST_DB_PROVIDER value: ${val}`);
     }
     return val as 'sqlite' | 'postgresql';
 }

---

59-61: Gate noisy logs behind a flag

Reduce test output by logging only when explicitly enabled.

-    console.log(`Using provider: ${provider}, db: ${dbName}`);
+    if (process.env.VERBOSE_TESTS) {
+        console.log(`Using provider: ${provider}, db: ${dbName}`);
+    }

---

172-193: Postgres DB name derivation — LGTM, with a defensive fallback

Current logic is good. Consider a fallback if currentTestName is empty (rare in hooks).

-    invariant(testName);
+    invariant(testName, 'currentTestName is required to derive a unique DB name');

packages/runtime/test/client-api/typed-json-fields.test.ts (1)

23-27: Consider avoiding prisma db push for speed unless required

db push per test is expensive. If typed JSON constraints don't require Prisma schema application, prefer $pushSchema.

Please confirm whether these cases fail without usePrismaPush. If not required, removing it will significantly speed up this suite.

packages/runtime/test/client-api/raw-query.test.ts (2)

39-45: Avoid ts-ignore by checking the dialect provider instead of schema

Use the runtime dialect’s provider to select placeholder style; this removes the need for ts-ignore.

-        const sql =
-            // @ts-ignore
-            client.$schema.provider.type === 'postgresql'
+        const sql =
+            // runtime provider check avoids TS narrowing issues
+            (client.$options.dialect as any).provider === 'postgresql'
                 ? `UPDATE "User" SET "email" = $1 WHERE "id" = $2`
                 : `UPDATE "User" SET "email" = ? WHERE "id" = ?`;

---

71-77: Apply the same dialect-provider check here

Mirror the change for queryRawUnsafe.

-        const sql =
-            // @ts-ignore
-            client.$schema.provider.type === 'postgresql'
+        const sql =
+            (client.$options.dialect as any).provider === 'postgresql'
                 ? `SELECT "User"."id", "User"."email" FROM "User" WHERE "User"."id" = $1`
                 : `SELECT "User"."id", "User"."email" FROM "User" WHERE "User"."id" = ?`;

packages/runtime/test/client-api/find.test.ts (1)

676-698: Consider extracting the provider check to reduce code duplication.

The provider type check is repeated in multiple places. Consider extracting this into a helper function or using a more declarative approach.

+const isPostgreSQL = (client: ClientContract<typeof schema>) => 
+    client.$schema.provider.type === 'postgresql';

 // @ts-ignore
-if (client.$schema.provider.type === 'postgresql') {
+if (isPostgreSQL(client)) {

packages/runtime/src/client/crud/dialects/postgresql.ts (1)

74-83: Consider handling edge cases for BigInt conversion.

While the BigInt transformation handles string and number inputs, consider adding validation for numeric string formats and potential overflow scenarios.

 private transformOutputBigInt(value: unknown) {
     if (typeof value === 'bigint') {
         return value;
     }
     invariant(
         typeof value === 'string' || typeof value === 'number',
         `Expected string or number, got ${typeof value}`,
     );
+    // Validate string format if it's a string
+    if (typeof value === 'string' && !/^-?\d+$/.test(value.trim())) {
+        throw new QueryError(`Invalid BigInt string format: ${value}`);
+    }
     return BigInt(value);
 }

packages/runtime/test/client-api/delegate.test.ts (1)

785-793: Standardize and document polymorphic-model "limit" error messages.

Found: packages/runtime/src/client/crud/operations/base.ts throws "Updating with a limit is not supported for polymorphic models" and "Deleting with a limit is not supported for polymorphic models"; test asserts update message in packages/runtime/test/client-api/delegate.test.ts. No README/docs reference detected.

Actions:

• Standardize wording across operations (suggest canonical form: "The with a limit is not supported for polymorphic models") and align the "skipDuplicates" message grammar/quoting in the same file.
• Add a short docs entry (README or developer docs) listing this polymorphic-model limitation and affected operations.
• Update tests if the exact error strings are changed.

packages/runtime/src/client/crud/dialects/sqlite.ts (2)

45-51: Avoid mixed storage formats for DateTime on writes

Numbers currently pass through unchanged, while strings and Dates become ISO strings. That can lead to mixed TEXT/NUMERIC representations in the same column and inconsistent comparisons. Recommend normalizing numeric inputs to ISO strings too.

Apply:

-                    .with('DateTime', () =>
-                        value instanceof Date
-                            ? value.toISOString()
-                            : typeof value === 'string'
-                              ? new Date(value).toISOString()
-                              : value,
-                    )
+                    .with('DateTime', () =>
+                        value instanceof Date
+                            ? value.toISOString()
+                            : typeof value === 'string'
+                              ? new Date(value).toISOString()
+                              : typeof value === 'number'
+                                ? new Date(value).toISOString()
+                                : value,
+                    )

If you prefer storing epoch numbers in SQLite, we should instead coerce everything (Date/string) to a number and align getFieldSqlType accordingly. Confirm the intended representation and we’ll adjust both paths.

---

98-100: Broaden boolean normalization for common SQLite representations

better-sqlite3 often returns 0/1; sometimes strings “0”/“1” appear via views/expressions. Handle these explicitly to avoid surprises.

Apply:

-    private transformOutputBoolean(value: unknown) {
-        return !!value;
-    }
+    private transformOutputBoolean(value: unknown) {
+        if (typeof value === 'number') return value !== 0;
+        if (typeof value === 'string') return value === '1' || value.toLowerCase() === 'true';
+        return !!value;
+    }

packages/runtime/src/client/functions.ts (3)

81-87: Null semantics in isEmpty: consider COALESCE for predictable behavior

As written, NULL arrays yield NULL = 0 (unknown/false). If "null means empty" is desired, coalesce to 0.

-    return eb(dialect.buildArrayLength(eb, field), '=', sql.lit(0));
+    return eb(eb.fn('coalesce', [dialect.buildArrayLength(eb, field), sql.lit(0)]), '=', sql.lit(0));

---

109-124: Typo: "casting" → "casing" in error message

Minor copy fix.

-    invariant(ValueNode.is(opNode) && typeof opNode.value === 'string', '"casting" parameter must be a string value');
+    invariant(ValueNode.is(opNode) && typeof opNode.value === 'string', '"casing" parameter must be a string value');

---

1-1: Add the readBoolean helper

Place this helper near processCasing or above the exports to support the proposed changes.

function readBoolean(expr: Expression<any> | undefined, paramName: string): boolean {
    if (!expr) return false;
    const node = expr.toOperationNode();
    invariant(ValueNode.is(node) && typeof node.value === 'boolean', `"${paramName}" parameter must be a boolean literal`);
    return node.value;
}

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

packages/runtime/test/policy/policy-functions.test.ts (5)

5-24: Default case-sensitive test is correct; tweak naming and provider-check phrasing

• Rename the test to clarify it verifies the default (implicit) behavior.
• The comment “sqlite is always case-insensitive” is over-broad; SQLite’s LIKE/INSTR are ASCII‑case‑insensitive by default. Consider clarifying.
• Optional: factor the provider check into a local isSQLite for readability.

Apply:

-it('supports contains case-sensitive', async () => {
+it('supports contains case-sensitive (default)', async () => {
@@
-        await expect(db.foo.create({ data: { string: 'bcd' } })).toBeRejectedByPolicy();
-        if (db.$schema.provider.type === 'sqlite') {
-            // sqlite is always case-insensitive
+        await expect(db.foo.create({ data: { string: 'bcd' } })).toBeRejectedByPolicy();
+        const isSQLite = db.$schema.provider.type === 'sqlite';
+        if (isSQLite) {
+            // SQLite LIKE/INSTR are ASCII-case-insensitive by default
             await expect(db.foo.create({ data: { string: 'Acd' } })).toResolveTruthy();
         } else {
             await expect(db.foo.create({ data: { string: 'Acd' } })).toBeRejectedByPolicy();
         }

---

26-46: Explicit case-sensitive mirrors default; reduce duplication

These assertions duplicate the prior test with the explicit flag. Consider describe.each to parameterize (implicit vs explicit) and collapse duplication.

Example:

describe.each([
  { name: 'default', expr: "contains(string, 'a')" },
  { name: 'explicit', expr: "contains(string, 'a', false)" },
])('supports contains case-sensitive: %s', ({ expr }) => {
  // build schema with `${expr}` and run the same expectations
});

---

80-85: SQLite note: ASCII-only case-insensitivity and PRAGMA caveat

If tests ever use non-ASCII letters or PRAGMA case_sensitive_like = ON, expectations will differ. Add a brief note or guard to prevent future false failures.

Would you like me to add a tiny regression test using a non-ASCII character to document this?

---

141-144: Duplicate assertion; remove the extra line

Line 142 repeats Line 141 and adds no value. Drop it.

Apply:

         await expect(anonDb.foo.create({ data: {} })).toBeRejectedByPolicy();
-        await expect(anonDb.foo.create({ data: {} })).toBeRejectedByPolicy();

---

233-233: Remove console.log from tests

Stray logging adds noise to CI output.

Apply:

-        console.log(created);

packages/language/res/stdlib.zmodel (5)

126-129: Doc: default matching isn't universally case-sensitive; clarify dialect behavior.

SQLite/MySQL default LIKE may be case-insensitive depending on collation; Postgres LIKE is case-sensitive. Recommend wording that reflects provider/collation variance and mentions the CI emulation strategy. Also fix parameter spelling in docs.

Apply:

- * Checks if the field value contains the search string. By default, the search is case-sensitive, and
- * "LIKE" operator is used to match. If `caseInSensitive` is true, "ILIKE" operator is used if
- * supported, otherwise it still falls back to "LIKE" and delivers whatever the database's 
- * behavior is.
+ * Checks if the field value contains the search string. By default, matching follows the database's
+ * collation and LIKE semantics. If `caseInsensitive` is true, use "ILIKE" where supported (e.g. PostgreSQL);
+ * otherwise use a dialect-specific best‑effort (e.g. LOWER(field) LIKE LOWER(search)) or fall back to LIKE,
+ * so behavior may vary by provider/collation.

---

141-145: Doc: mirror the dialect-aware wording for startsWith.

Same concerns as contains(); also fix param spelling.

- * Checks the field value starts with the search string. By default, the search is case-sensitive, and
- * "LIKE" operator is used to match. If `caseInSensitive` is true, "ILIKE" operator is used if
- * supported, otherwise it still falls back to "LIKE" and delivers whatever the database's 
- * behavior is.
+ * Checks the field value starts with the search string. By default, matching follows the database's
+ * collation and LIKE semantics. If `caseInsensitive` is true, use "ILIKE" where supported; otherwise apply
+ * a dialect-specific best‑effort or fall back to LIKE, so behavior may vary by provider/collation.

---

146-147: Parameter name: use caseInsensitive.

-function startsWith(field: String, search: String, caseInSensitive: Boolean?): Boolean {
+function startsWith(field: String, search: String, caseInsensitive: Boolean?): Boolean {

---

150-154: Doc: mirror the dialect-aware wording for endsWith.

And fix param spelling.

- * Checks if the field value ends with the search string. By default, the search is case-sensitive, and
- * "LIKE" operator is used to match. If `caseInSensitive` is true, "ILIKE" operator is used if
- * supported, otherwise it still falls back to "LIKE" and delivers whatever the database's 
- * behavior is.
+ * Checks if the field value ends with the search string. By default, matching follows the database's
+ * collation and LIKE semantics. If `caseInsensitive` is true, use "ILIKE" where supported; otherwise apply
+ * a dialect-specific best‑effort or fall back to LIKE, so behavior may vary by provider/collation.

---

155-156: Parameter name: use caseInsensitive.

-function endsWith(field: String, search: String, caseInSensitive: Boolean?): Boolean {
+function endsWith(field: String, search: String, caseInsensitive: Boolean?): Boolean {

packages/runtime/test/client-api/relation/self-relation.test.ts (1)

489-505: Clarify semantics: deleteMany on M2M deletes records, not just disconnects

The comment says “disconnect and delete,” but nested deleteMany under a M2M relation deletes the matched related records themselves (thus removing all of their relations). The subsequent assertions depend on this (David deleted, Eve remains). Update the comment to avoid confusion.

-        // Test deleteMany operation (disconnect and delete)
+        // Test deleteMany operation (delete related records; not just disconnect)

packages/runtime/src/client/crud/dialects/base-dialect.ts (1)

1262-1271: New dialect APIs are not yet applied in base string filters

You added getStringCasingBehavior but buildStringFilter (Lines 650–703) still hardcodes ILIKE/LIKE without consulting it. Consider delegating casing to the dialect to avoid SQLite incompatibilities and keep behavior consistent with functions.ts.

- .with('contains', () =>
-     mode === 'insensitive'
-         ? eb(fieldRef, 'ilike', sql.val(`%${value}%`))
-         : eb(fieldRef, 'like', sql.val(`%${value}%`)),
- )
+ .with('contains', () => this.buildLike(eb, fieldRef, `%${value}%`, mode))

And add a small helper in this class that uses getStringCasingBehavior to pick operator or lower both sides.

packages/runtime/src/client/crud/dialects/sqlite.ts (1)

118-128: Surface better error context for JSON parse failures

Minor: include dialect/source in the message to aid triage.

-            } catch (e) {
-                throw new QueryError('Invalid JSON returned', e);
+            } catch (e) {
+                throw new QueryError('Invalid JSON returned from SQLite', e);
             }

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

packages/runtime/src/client/crud/operations/base.ts (4)

365-367: Sequential post-create relation handling: OK, but watch for perf regressions

Switching from batched to sequential awaits improves determinism, but can slow large nested create trees. If DB constraints don’t require strict ordering, consider a bounded-concurrency approach.

Example (conceptual):

- for (const [field, subPayload] of Object.entries(postCreateRelations)) {
-     await this.processNoneOwnedRelationForCreate(kysely, model, field, subPayload, createdEntity);
- }
+ for (const entries of chunk(Object.entries(postCreateRelations), 8)) {
+   await Promise.all(entries.map(([field, subPayload]) =>
+     this.processNoneOwnedRelationForCreate(kysely, model, field, subPayload, createdEntity)
+   ));
+ }

---

1365-1367: Sequentializing nested updates: consistent, but consider bounded concurrency for large batches

The move from Promise.all to for-await avoids interleaving and simplifies error surfaces. For high-cardinality relations, a small concurrency pool (e.g., 8–16) often yields better throughput without stressing the DB.

Also applies to: 1373-1379, 1384-1384, 1389-1389, 1394-1394, 1401-1401, 1405-1417, 1422-1441, 1446-1449, 1454-1454, 1459-1459

---

1591-1598: Avoid redundant read on connectOrCreate

You already have the existing entity’s ids from exists; pass them directly to connectRelation to skip another lookup.

- for (const { where, create } of _data) {
-     const existing = await this.exists(kysely, model, where);
-     if (existing) {
-         await this.connectRelation(kysely, model, [where], fromRelation);
-     } else {
-         await this.create(kysely, model, create, fromRelation);
-     }
- }
+ for (const { where, create } of _data) {
+     const existing = await this.exists(kysely, model, where);
+     if (existing) {
+         await this.connectRelation(kysely, model, existing, fromRelation);
+     } else {
+         await this.create(kysely, model, create, fromRelation);
+     }
+ }

---

597-612: processNoneOwnedRelationForCreate: tighten type; transaction wrapping verified

• Type nit — align cast with createMany's signature:

- subPayload as { data: any; skipDuplicates: boolean },
+ subPayload as { data: any; skipDuplicates?: boolean },

• Transaction check — verified top-level create/createMany are executed inside safeTransaction and pass the tx/kysely down (packages/runtime/src/client/crud/operations/create.ts → create(tx, ...)); relation handlers accept a kysely/tx (packages/runtime/src/client/crud/operations/base.ts), so connectOrCreate runs under the same transaction and the TOCTOU concern is mitigated.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

packages/language/test/delegate.test.ts (1)

8-12: DRY the datasource and make provider/url configurable

Same note as mixin tests: inline sqlite blocks are fine but duplicate and make pg runs less representative. Replace with a shared ds snippet.

-        datasource db {
-            provider = 'sqlite'
-            url      = 'file:./dev.db'
-        }
+        ${ds}

If you prefer not to introduce ${ds} interpolation, alternatively wrap fixtures:

// utils
export const withDatasource = (s: string) => `${ds}\n${s}`;
// usage
const model = await loadSchema(withDatasource(`
model A { ... }
`));

Also applies to: 33-36, 54-57, 76-79, 98-101

packages/language/test/import.test.ts (2)

15-19: Use shared datasource snippet to keep imports fixture provider‑agnostic

Replacing the literal block with ${ds} keeps this test neutral across pg/sqlite.

-datasource db {
-  provider = 'sqlite'
-  url      = 'file:./dev.db'
-}
+${ds}

---

57-61: Same refactor for other fixtures in this file

Apply the same ${ds} substitution to avoid drift between fixtures and support the CI matrix cleanly.

Also applies to: 80-84

packages/language/test/mixin.test.ts (1)

8-12: Replace hardcoded sqlite datasource with a shared env-driven snippet

Multiple tests embed identical datasource blocks with provider = 'sqlite'. Replace them with a shared, env-driven ds snippet to support a sqlite/postgres test matrix and reduce duplication.

-        datasource db {
-            provider = 'sqlite'
-            url      = 'file:./dev.db'
-        }
+        ${ds}

Add once per file (or export from a shared test util):

// test datasource snippet (env-driven; parsing only, no connect)
const ds = `
datasource db {
  provider = '${process.env.TEST_DB_PROVIDER ?? 'sqlite'}'
  url      = '${process.env.TEST_DB_URL ?? 'file:./dev.db'}'
}
`;

Locations to update:

• packages/language/test/mixin.test.ts — blocks at lines ~8–12, 33–37, 65–69
• packages/language/test/import.test.ts — blocks at lines ~15–18, 57–60, 80–83
• packages/language/test/delegate.test.ts — blocks at lines ~8–11, 32–35, 53–56, 75–78, 97–100
• packages/language/test/expression-validation.test.ts — block at lines ~57–60

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-04T12:38:14.150Z
Learning: Applies to **/schema.zmodel : Name ZModel schema files `schema.zmodel`

packages/language/test/import.test.ts (2)

70-70: Avoid index-based lookup; select model/field by name

Indexing into model.declarations and fields is fragile with added blocks. Use name-based lookup.

Apply this diff:

-        expect((model.declarations[1] as DataModel).fields[1].type.reference?.ref?.name).toBe('Role');
+        const user = model.declarations.filter(isDataModel).find((d) => d.name === 'User')!;
+        const roleField = user.fields.find((f) => f.name === 'role')!;
+        expect(roleField.type.reference?.ref?.name).toBe('Role');

---

106-106: Same brittleness here; prefer name-based selection

Selecting by index can break as declarations reorder. Use model/field names.

Apply this diff:

-        expect((modelA.declarations[1] as DataModel).fields[1].type.reference?.ref?.name).toBe('B');
+        const aModel = modelA.declarations.filter(isDataModel).find((d) => d.name === 'A') as DataModel;
+        const bField = aModel.fields.find((f) => f.name === 'b')!;
+        expect(bField.type.reference?.ref?.name).toBe('B');

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: CR
PR: zenstackhq/zenstack-v3#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-04T12:38:14.150Z
Learning: Applies to **/schema.zmodel : Name ZModel schema files `schema.zmodel`